TeX 1995 July/TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO/tex-k/tex-k-archive.past/tex-k-archive.gz/tex-k-archive/[e-mail]_Tue Jun 14 06:37:52 1994.msg

Internet Message Format | 1994-10-11 | 2KB

Received: from stat.ufl.edu by cs.umb.edu with SMTP id AA20786
  (5.65c/IDA-1.4.4 for <[e-mail]>); Tue, 14 Jun 1994 10:41:55 -0400
Received: from clam (clam.stat.ufl.edu [128.227.141.101]) by stat.ufl.edu (8.6.8.1/8.6.8) with ESMTP id KAA27366 for <<[e-mail]>>; Tue, 14 Jun 1994 10:35:49 -0400
Received: from localhost (presnell@localhost) by clam (8.6.8.1/8.6.8) with SMTP id KAA09509 for <[e-mail]>; Tue, 14 Jun 1994 10:37:53 -0400
Message-Id: <199406141437.KAA09509@clam>
To: [e-mail]
Subject: A better way to generate the ls-R file?
Date: Tue, 14 Jun 1994 10:37:52 -0400
From: "Brett Presnell <[e-mail]


We use depot (from CMU) to maintain software, and so inevitably have
links in subdirectories of /usr/local/lib/texmf which neither kpathsea
NOR ls -R will follow.  Instead of either disabling the speedup in kpathsea
or putting in a dummy directory, we simply use the ls-R database
mechanism, but we generate the ls-R file by typing

    ls -LR /usr/local/lib/texmf > ls-R

so that ls will follow the links.  I suppose we could now disable the
speedup, but since we intend to keep the ls-R file up to date, I don't
imagine that we'll bother.  Anyway, I simply wanted to suggest that
perhaps this bit of advice be added to the documentation; it works
wonderfully for us.  In fact, I don't suppose there's any reason not
to advise that the ls-R file be created at this way in any case.
Should it be renamed to ls-LR?

--
Brett Presnell        [e-mail]